Build should behave similarly, using a uv in the path if there's no uv package installed?

https://github.com/pypa/build/blob/ed9c379f51abca7c0c0ae20bee66aa548d597dc3/src/build/env.py#L305-L307

Build should behave similarly, using a uv in the path if there's no uv package installed?

If cibuildwheel's uv extra is not exposed in the PATH (as proposed in #2673) then build won't find uv unless it was installed with its own uv extra. See https://github.com/mayeut/cibuildwheel/actions/runs/20258197705/job/58164557217 for a failure when #2673 is applied on Windows which does not install build's uv extra.

I see you opened an issue in build and that's probably a good thing which should be applied ecosystem wide and would allow for an easier resolution.

Hmm. All this is starting to feel a little messy/hacky. I'm thinking there's another option here, where we say that if the build-frontend uses uv, we require the caller of cibuildwheel to ensure that uv is somewhere on PATH (and bail if it's not found). So, we don't even attempt to look in the python import path for it. That way we'll be sure that build can use it too.

In the case of the github action, we could just use astral/setup-uv conditionally, and keep the direct invocation there?

As I see it, the cibuildwheel[uv] extra would continue to work in this setup, assuming that users have the virtualenv active when they call cibuildwheel (this must be the most common setup, I'd expect).

closing for the same reasons as explained in #2696 (comment)
If the user wants to use uv directly from commands, it's their responsibility to make sure it's in PATH.
Alternatives I see to fixing this are:

• rewrite commands from the user as proposed in Fix the PATH computation in GHA on windows, and require uv on PATH #2696 (comment) but this will not cover the case of uv being called from a script used as a command.
• link or copy/expose uv in PATH when cibuildwheel starts (different from this PR)